SQL Azure : Design Factors (part 1)

Storing data in SQL Azure is similar to storing data in SQL Server. All you need to do is issue T-SQL statements and review some of the limitations of the syntax specific to SQL Azure, and off you go!

The ability to store data in SQL Azure using T-SQL offers unique opportunities. In many cases, you can easily extend or port certain types of applications in SQL Azure with no (or limited) modifications. This portability allows you either to implement solutions that directly depend on SQL Azure for storage, or to use a local database while using SQL Azure transparently for additional storage requirements (such as reporting).

However, keep in mind that you're limited to the amount of data you can store in a single SQL Azure database. At the moment, SQL Azure supports two editions: Web Edition (1GB or 5GB) and Business Edition (from 10GB to 50GB in 10GB increments). So, if your application needs to store more than 50GB of data, or if your database can benefit from a multithreaded data access layer, you need to consider splitting your data across multiple databases through a form of partitioning called a shard.

2. High Availability

When designing applications, software developers and architects are usually concerned about high-availability requirements. SQL Azure uses a very elaborate topology that maximizes workload redistribution, transparency, and recovery. Figure 1 shows a high-level implementation of SQL Azure that gives a hint about how advanced the backend infrastructure must be.

Figure 1. SQL Azure topology

Figure 1 illustrates that connections are made through a load balancer that determines which gateway should process the connection request. The gateway acts as a firewall by inspecting the request, performing authentication and authorization services, and forwarding the packets to an actual SQL Azure database. Because databases can be moved dynamically to ensure fair resource allocation, the gateway may alter the destination endpoint. The process is mostly transparent.

In addition, each SQL Azure database is replicated twice on different servers for redundancy. Behind the scenes, a replication topology ensures that a SQL Azure database exists on two other physical servers at all times. These two additional copies are totally transparent to consumers and can't be accessed.

3. Performance

Performance of applications you write can be affected by two things: throttling and how you design the application. Microsoft has put performance throttling in place to prevent one client's applications from impacting another. (It's a good feature, not nearly so bad as it may sound.) Application design is something you control.

3.1. Throttling

SQL Azure runs in a multitenant environment, which implies that your databases share server resources with databases from other companies. As a result, the SQL Azure platform has implemented a throttling algorithm that prevents large queries from affecting other users from a performance standpoint. If your application issues a large query that could potentially affect other databases, your database connection is terminated.

In addition, to preserve valuable resources and control availability, SQL Azure disconnects idle sessions automatically. The session timeout is set to 30 minutes. When you're designing for SQL Azure, your application should account for automatic session recovery. This also means that performance testing in your development phase becomes more critical.

3.2. Application Design Considerations

When considering how to design your application to best take advantage of SQL Azure, you need to evaluate the following items:

• Database roundtrips. How many roundtrips are necessary to perform a specific function in your application? More database roundtrips mean a slower application, especially when the connection is made over an Internet link and is SSL encrypted.

• Caching. You can improve response time by caching resources on the client machine or storing temporary data closer to the consumer.

• Property lazy loading. In addition to reducing roundtrips, it's critical to load only the data that's absolutely necessary to perform the required functions. Lazy loading can help significantly in this area.

• Asynchronous user interfaces. When waiting is unavoidable, providing a responsive user interface can help. Multithreading can assist in providing more responsive applications.

• Shards. A shard is a way of splitting your data across multiple databases in a manner that is as transparent as possible to your application code, thus improving performance.

Designing an application for performance becomes much more important for cloud computing solutions that depend on remote storage.

4. SQL Data Sync Framework

The SQL Data Sync framework offers bidirectional data-synchronization capabilities between multiple data stores, including databases. SQL Data Sync uses the Microsoft Sync Framework, which isn't limited to database synchronization; you can use the framework to synchronize files over different platforms and networks.

Specifically as it relates to SQL Azure, you can use the Sync framework to provide an offline mode for your applications by keeping a local database synchronized with a SQL Azure database. And because the framework can synchronize data with multiple endpoints, you can design a shard, described later, in which all databases keep their data in sync transparently.